In powerful digital data processors, multiple, substantially autonomous data units are commonly employed to allow concurrent or "overlapped" execution of instructions, wherein a different instruction may be simultaneously executing in each of the data units. In simple data units, each instruction may take only a single machine cycle to execute, so that a new instruction may be "issued" to the data unit every machine cycle. In complex data units, several machine cycles may be required to execute an instruction, so that a subsequent instruction for that data unit cannot be issued until the data unit has completed the last instruction issued to it. To minimize the likelihood of such "stalls", the complex data unit may be constructed as a series of relatively independent "stages" which together comprise a "pipeline", such that a different instruction can be concurrently executing at each stage of the pipeline. Both techniques, overlapping and pipelining, allow greater increased performance. However, having paid the price in hardware to enable the higher performance level, considerable additional investment must be made in sophisticated optimizing compilers and scheduling hardware to fully realize the potential performance levels.
In general, some types of exception conditions are detectable at the beginning of execution of an instruction, while other types of exception conditions are only detectable during or after execution. For example, an attempt to divide by zero can be easily detected before execution is initiated, and an appropriate "trap" signal generated. Since the data processor has not yet proceeded to issue the next instruction, the exception can be recognized immediately, before the state of the processor has changed. Such an exception condition is referred to as "precise", since the state of the data processor, including all of the data units, as of the time the trapped instruction was issued is known precisely. Such precise exception handling mechanisms are common in conventional, serial data processors such as the Motorola MC68020 microprocessor. (See, MC68020 32-Bit Microprocessor User's Manual. Second Edition, 1985, page 6-10.)
In contrast, an overflow or underflow condition which occurs as a result of an arithmetic operation will typically be detected some time after the issuance of the instruction which caused that condition. Since the data processor will have continued to issue subsequent instructions in the instruction stream, it is possible that at least one of those subsequent instructions will have completed and irreversibly changed the state of the processor. If no sequence of instructions can be executed after the trap to precisely recreate the state of the processor as of the time the trapping instruction was issued, the exception is referred to as "imprecise". Conventional serial data processors, such as the MC68020, are equipped with an imprecise exception handling mechanism. (See, MC68020 32-Bit Microprocessor User's Manual, Second Edition, 1985, Appendix A1-A4).
Although many high performance data processors have permitted imprecise exceptions, most did so based on the assumption that a trap implies a fatal error such that the continued correct execution is not necessary. Processors exhibiting such imprecise exception behavior include the IBM System 360 Model 91, the Texas Instruments Advanced Super Computer, the Control Data Corporation 6600, 7600 and Star 100, and the Cray Model 1. In some of these, particularly the CDC processors, the arithmetic algorithms were simply "defined" as being incapable of generating an exception condition and always delivered a result in a predictable form regardless of the situation. In contrast, IEEE compliant floating-point arithmetic requires the recognition of certain exceptional conditions. When the processor itself is incapable of recognizing such "required" exceptions conditions, a complex (and slow) software envelope must be provided to detect the exception copnditions "before" they would otherwise have occurred, and then handle them accordingly. In general, the advantage to allowing imprecise exceptions is increased speed of execution in the pipelined data units, while the disadvantage is the greatly increased difficulty (or impossibility) of recovering from the trap condition using "smart" trap software.
One proposed technique for overcoming the disadvantage of allowing imprecise exceptions is to allow each instruction to cause "temporary" changes of state which will become permanent only if all instructions preceeding that instruction in the instruction stream successfully complete execution, but which will be "undone" otherwise. However, the hardware necessary to "remember" all of the "temporary" changes of state and to keep track of the instruction stream dependencies is quite extensive.
It would be desirable to provide a hardware-efficient technique whereby sufficient information would be readily available as of the time an imprecise exception is detected to enable the trapping instruction to be completed, if possible, in either hardware or software, or, in the alternative, that the information that is readily available is sufficient to allow the trapped instruction to be recovered.